A security token—also referred to as a hardware token, authentication token, USB token, cryptographic token, or key fob—is a physical device which facilitates remote access to computing services, for example in the so-called “cloud”, and which improves the security of (remote) authentication. The security token makes a login code available, for example on a display or via USB, which the owner of the token may use to log in to a particular computing service. This type of authentication is called two-factor authentication, since the user needs, besides the normal user account details, also the security token to be able to get access.
Security tokens are typically used in connection with a desktop PC or a laptop to access corporate computing services or networks or on-line bank accounts. In recent years, more and more cloud-based consumer services have also started to offer two-factor authentication. Examples include Google, Amazon Web Services, Dropbox, Wordpress, DreamHost, Drupal and Lastpass.
Login codes generated by more advanced security tokens are usually based on the current time of day. The security token will therefore contain a clock and a battery in order to be able to keep the time. To enhance the security of the authentication process, a direct connection between the (back-end) computing service and the security token is preferred, for example to be able to authenticate by performing a cryptographically secure challenge-response protocol with the back-end. The OATH standard provides a set of commonly used authentication protocol specifications that include both time-based and challenge-response based authentication mechanisms.
Currently, a direct connection between a security token and a back-end server is usually accomplished by using a security token in the form of e.g. a smart card, a USB dongle or a Bluetooth token inserted or connected to the PC on which the user accesses the service. The challenge-response protocol removes the need for a clock and, hence, in case of a smart card or a USB dongle, the need for a battery. In practice, systems sometimes combine time-based authentication and challenge-response-based authentication. For example, on-line banking time-based authentication is used to get read access to transaction records, while challenge-response authentication is used to for entering new transactions.
Increasingly, computer users are using mobile devices such as mobile phones and tablets (e.g. iPad) to access such cloud and other computing services. Mobile devices usually do not have a smart card slot and often have no USB-host capability. Bluetooth is often present on such devices, but usually only to support particular kinds of devices, such as an audio headset or keyboard and mouse. It is quite often not easy (or with some mobile platforms even impossible) to install additional support for other types of Bluetooth devices such as a Bluetooth security token. Alternative solutions for mobile devices exist, for example using the standard audio jack for input.
Another approach for mobile devices, such as smart-phones, is to implement a security token in the form of software: a so-called “app”, i.e. a computer program, on the mobile devices functions like a stand-alone security token. The user can type in the login code displayed on his mobile device into his laptop or computer. Alternatively, if the computing service is accessed on the mobile device itself, the login code can be copied from the security-token app to the clipboard and then pasted into the required field in the app where the login screen for the computing service is displayed (e.g. in the web browser). A well-known example of such an app is Google's Authenticator app, available for several mobile platforms. However, the largest drawback of this approach is the potential lack of security: a mobile device is an open system, with a complicated operating system, many different software programs running and an always-on connection to the internet. This is at odds with the requirement that the mobile device itself needs to be authenticated, because it cannot be trusted per se.
Nowadays, more and more mobile devices, as well as PC's and laptops, are being equipped with an NFC (Near Field Communication) interface. The mobile operating system (e.g. Android and BlackBerry OS) in such devices has specific support for handling NFC connections in such a way as to make this easy and intuitive for consumers (e.g. automatic dispatching of so-called NDEF messages to start up the right app without user intervention). Therefore, equipping a security token with an NFC-compatible interface makes a lot of sense, especially if this can be combined with a way to take advantage of the mobile device's built-in support for NFC that makes it even easier and more convenient to use a security token for the consumer.
Recently, the company Yubico (http://www.yubico.com/) announced such an NFC-enabled security token. It is an enhancement to their existing USB-based products. The USB version of the product merely functions as an automatic keyboard that fills in the authentication code for the user (i.e. it eliminates the need for the user to copy the code form a display on the token). The NFC version of the product is similar: it provides the login code as part of a URL stored in an NDEF message on the device. The NFC-enabled mobile device reads out this NDEF message automatically and the proper app is started. So, again, the user does not have to copy the login code, but it is filled in automatically, like with the USB version of the product.
In general, NFC-enabled security tokens suffer from a number of drawbacks relating to security, ease-of-use and multi-application support.
Security
Creating a software app that implements a security token may be convenient, but it is, generally speaking, not secure enough. The integration of a contactless (ISO 14443) or NFC (ISO 18092) interface with a security token presents new challenges that are potentially security risks. For example, when the owner of a security token has the token in his/her pocket or bag, other people have no access to it. Access to the USB interface is essentially blocked and any display is invisible. The situation with NFC is different: as the communication is contactless, it is possible to communicate with an NFC-enabled security token right through a layer of cloth, plastic or other non-metal-containing material. For security reasons, it becomes therefore necessary to add a layer of access control to the security token itself.
Ease-of-Use
The need to copy the login code from a display of a security token is inconvenient for users. Even a mobile app like Google's Authenticator still does not make it really easy in the situation that the computing service is accessed on the same mobile device by requiring manual copying and pasting of the login code. Sometimes, security tokens are equipped with a key pad and display. The user then has to enter a personal identification number (PIN) first in order to obtain the desired log-in code. In some cases, the security token is a combination of a smart card and a (battery-powered) smart card reader with its own key pad, display and built-in clock. In that case, the combination of the smart card reader and the smart card effectively form the security token. In case of an NFC-enabled security token, however, this is highly unpractical, as the user would have to interact with his mobile device and the security token at the same time, because they have to be kept close together for the NFC connection to work.
Multiple-application Support
Currently, security tokens are generally used only for access to one single application or service. Certainly for the simplest kind of token, with only a display and no buttons or other interfaces, there is simply no possibility to support multiple applications, unless they would use the exact same security parameters in the token.